Add EVM support#299
Draft
akobrin1 wants to merge 13 commits into
Draft
Conversation
Supernode's startup migration path holds a single signing key and cannot run the K-of-N ceremony required for a multisig legacy account. Detect is_multisig=true from MigrationEstimate and return an actionable error pointing to lumerad's 4-step offline flow (generate-proof-payload → sign-proof → assemble-proof → submit-proof). After the operator completes the offline ceremony, the next restart finds the on-chain MigrationRecord and drives local cleanup through the existing alreadyMigrated branch — no new multisig-aware code in the daemon. Also log the new is_multisig/threshold/num_signers fields from QueryMigrationEstimate in the pre-flight summary, and bump the lumera pseudo-version pin to origin/evm HEAD (e09830d70704) so a clean checkout without ../lumera still resolves to a version that has the LegacyProof oneof, SingleKeyProof/MultisigProof types, and MaxMultisigSubKeys param. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
sncli transitively depends on lumera's app package (via x/lumeraid/securekeyx tests), which pulls in cosmos/evm's statedb → github.com/ethereum/go-ethereum/trie/utils. Upstream go-ethereum doesn't export that package; cosmos/evm requires the cosmos/go-ethereum fork. The main go.mod already has this replace; mirror it here so `go build ./...` from cmd/sncli resolves. Bump the lumera require to the pseudo-version at origin/evm HEAD (was v1.11.0 from before the EVM work) and let go mod tidy refresh the rest of the indirect graph to match the root module. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Lumera unified legacy and new sides under a single MigrationProof oneof. Wrap newSig in a SingleKeyProof and pass it via NewProof on both MsgMigrateValidator and MsgMigrateAccount. Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
# Conflicts: # .gitignore # go.mod # go.sum # p2p/kademlia/bootstrap.go # p2p/kademlia/dht.go # supernode/supernode_metrics/reachability_active_probing_test.go # tests/system/go.mod # tests/system/go.sum
- Bump cmd/sncli and tests/system to lumera v1.20.0-rc2; drop local ../lumera replace now that the EVM-enabled release exists upstream. - tests/system: bump devnet tx fee to 1000ulume and make initSDKConfig idempotent so multiple test invocations don't trip the SDK's "Config is sealed" panic. - CHANGELOG: add Upcoming EVM Release section summarising the evm-support work (migration flow, keyring, p2p reactions, deps). Co-Authored-By: Claude Opus 4.7 (1M context) <noreply@anthropic.com>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Summary
This PR adds broad EVM support across supernode, SDK, CLI, and supporting modules, then brings the branch current with
master. The migration tooling is one part of the branch, but the overall change is larger: it updates account/key handling, Lumera dependencies, client interfaces, signing paths, and operator workflows for the EVM-enabled Lumera stack.What changed
eth_secp256k1keys and the EVM coin type 60 derivation path (m/44'/60'/0'/0/0).secp256k1accounts.evmigrationsupernode command, including proof generation/validation coverage and integration tests.docs/evm-migration.mdfor the migration workflow.cmd/sncli,sn-manager, andtests/systemwith the EVM-enabled Lumera stack.masterchanges via merge commit25589ad, including the host reporter storage-full compatibility updates from80ecbb7.Why
The EVM-enabled Lumera path requires supernode and related tools to produce and understand EVM-compatible account keys, updated signing/proof payloads, and the newer Lumera module APIs. Without these changes, operators and developers would only have partial migration tooling, while normal account creation/recovery and SDK flows would still use the legacy key model.
User and developer impact
evmigrationworkflow for preparing migration proofs.Validation
go test ./...passed locally from the repository root on 2026-05-27.Notes
This is the broader EVM support branch, not only an EVM migration PR. The migration command and docs are included because they are part of the operator path for adopting the EVM-enabled stack.